Virtual Private Networking (abbreviated as “VPN”) refers to establish a private network in a public network, so that the data can be transmitted via a secure “encrypted channel” in the public network. The respective branches of an enterprise can transfer information to each other once they access Internet locally via leased local private data lines; in addition, the enterprise can also enable its users to dial up to Internet and then access the Intranet by means of Internet dial-up access devices. The VPN has advantages of reduced cost, remote access support, high extension, easy management and overall control, etc.
Multi-Protocol Label Switch (abbreviated as “MPLS”) is a standard protocol of Internet Engineering Task Force (abbreviated as “IETF”), evolved from CISCO's Tag Switching. MPLS is a label-based Internet Protocol (abbreviated as “IP”) routing method and belongs to L3 switching technique. It introduced a label-based mechanism to separate routing from forwarding; that is, the route of a packet in the network is determined by the label, and data transmission is accomplished via a Label Switch Path (abbreviated as “LSP”). MPLS converts L3 packet switching in an IP network into L2 packet switching. The label includes a 3-bit EXP field to implement QoS.
FIG. 1 shows the structure of a MPLS network. As shown in FIG. 1, the MPLS network 101 includes Label Switch Routers (abbreviated as “LSR”) 104 in the core part and Label Edge Routers (abbreviated as “LER”) 103 in the edge part. Wherein, LERs 103 are designed to analyze IP packet headers, execute L3 network function, determine corresponding transmission class and Label Switch Path (abbreviated as “LSP”), and the LERs 103 are connected with external networks 102 and receive external packed switched data packets (IP packets) 105 from the external networks 102; the LSRs 104 are designed to establish LSPs, execute label switching mechanism and Quality of Service (QoS), and forward packed data packets (IP packets) 106 within the MPLS network, and each LSR 104 includes a control unit and a switching unit, located in the network, and is connected with LERs 103 and other LSRs 104.
The label switching work flow of MPLS is as follows: initially, a routing table and a label mapping table are created in LSR through Label Distribution Protocol (abbreviated as “LDP”) and conventional routing protocols, e.g., Open Shortest Path First (OSPF) protocol, etc; during network operation, first, the LER at the ingress of the MPLS core network receives IP packets from an external network, accomplishes L3 network function, adds a label in the IP packet to form a packed data packet; next, the packed data packet is transmitted via a LSP, in this case, the LSR do not perform L3 process for the packed data packet but only forward the packed data packet in accordance with the label via the switching unit, so that the packed data packet arrives at a LER at the opposite end (i.e., egress) of the network; finally, the LER at the egress of the MPLS network removes the label from the packed data packet, and proceeds to forward through corresponding protocol of the external network.
Since MPLS technique isolates label distribution mechanism from data stream, it can be implemented independently to specific data link layer protocols, and thereby can support diverse physical layer and data link layer techniques. At present, MPLS-based services have been implemented in Frame Relay (“FR”), Asynchronous Transfer Mode (“ATM”), and Point-to-Point Protocol (“PPP”) links, as well as local area network (LAN) that employs IEEE 802.3 protocol of Institute of Electrical and Electronics Engineers (“IEEE”). Employing a MPLS network for IP service forwarding can simplify the route forwarding procedures between layers, speed up MPLS switching, and improve network efficiency while meeting the requirements for services transmission of different grades; therefore, MPLS incorporates high speed flow control capability of switch and flexible functionality and QoS assurance mechanism of router.
MPLS has been widely used in implementation of VPNs. A VPN implemented on the basis of MPLS is referred to as a MPLS VPN.
MPLS VPNs can be classified into L3 (i.e., network layer) VPN, L2 (i.e., data link layer) VPN, L1 (i.e., physical layer) VPN, depending on the subscriber information that is used for forwarding by the network equipment. Presently, in the members of INTERNET ENGINEERING TASK FORCE (abbreviated as “IETF”), there are an L3 VPN workgroup and an L2 VPN workgroup, which study MPLS L3 VPN and MPLS L2 VPN, respectively. Typical examples of MPLS L3 VPN include Border Gateway Protocol (“BGP”) /MPLS VPN based on RFC 2547bis and IP VPN based on Virtual Router (“VR”). Typical examples of MPLS L2 VPNs include MARTINI, KOMPELLA, and implementing solutions of various Virtual Private LAN Segments (abbreviated as “VPLS”). Furthermore, SG 13/Q11 of International Telecommunication Union Telecommunication Standardization Sector (abbreviated as “ITU-T”) made a lot of investigations on L1 VPN, and presently, there are draft proposals such as Y.11vpnarch and Y.11vpnsdr, etc. Their reference models are similar in structure and VPN QoS processing, i.e., they don't take consideration of VPN QoS or utilize DiffServ capability of the network itself; therefore, above solutions can't solve the VPN QoS problem due to the same reason. In this respect, they can be concluded as the same technique.
Hereinafter the prior arts are described with RFC 2547bis as an example of this kind of techniques. Since they have the same reference model structures as L2 VPN and L3 VPN of ITU-T and IETF, they face the same challenge regarding QoS processing.
The MPLS L3 VPN model defined in RFC 2547bis is shown in FIG. 2. The model includes three components: Custom Edge Routers (abbreviated as “CEs”), Provider Edge Routers (abbreviated as “PEs”), and routers (P).
As a component of the customer premise network, a CE has an interface, usually a router, directly connected to the operator's network. CE can't “sense” existence of VPN and needn't to maintain the routing information of the entire VPN.
A PE is the operator's edge router. It is an edge device of the operator's network (also referred to as “backbone network”), and is directly connected to CEs. In an MPLS network, all processing work on VPN is accomplished in PEs.
As a backbone router in the operator's network, the router (P) is not connected directly with CEs. The router (P) shall have basic MPLS signaling capability and forwarding capability.
CEs and PEs are classified mainly in accordance with the administrative domains of the operator and subscribers; CEs and PEs form the boundary between the administrative domains.
CEs exchange routing information with PEs through Exterior Border Gateway Protocol (abbreviated as “EBGP”) or Interior Gateway Protocol (abbreviated as “IGP”) or via static routes.
It is unnecessary for CEs to support MPLS or sense the routes across the entire VPN; the routes across the entire VPN are contracted out to the operator for implementation. PEs exchange routing information across the entire VPN through Multi-Protocol Internal Border Gateway Protocol (abbreviated as “MP-IBGP”).
Hereinafter the attributes of MPLS L3 VPN specified in RFC 2547bis are described:
VRF:
A VPN includes multiple sites. In PE, each site corresponds to a VPN Routing/Forwarding (abbreviated as “VRF”) instance which mainly includes: IP routing table, label forwarding table, a cluster of interfaces that use the label forwarding table, and management information (including Route Distinguisher, route filtering policy, and member interface list, etc.)
A site can belong to multiple VPNs at the same time. In the implementation, each site has at least one separate VRF. Actually, the VRF(s) at a site in VPN combines the VPN membership and routing rules of the site. The message forwarding information is stored in the IP routing table and label forwarding table in each VRF. The system maintains a set of independent routing table and label forwarding table for each VRF, so as to prevent data leakage from the VPN and prevent external data from entering into the VPN.
VPN-IPv4 Address Family:
VPN routes are distributed among PEs in BGP, and a new address family of VPN-IPv4 address family is used.
A VPN-IPv4 address includes 12 bytes; wherein, the first 8 bytes refer to Route Distinguisher (abbreviated as “RD”), the rest 4 bytes refer to IPv4 address. PE identifies routing information from different VPNs by RD. The operator can allocate RDs independently, but has to take the ID of the dedicated Autonomous System (abbreviated as “AS”) as a part of RDs to ensure global uniqueness of each RD. A VPN-IPv4 address with RD=0 is synonymous to a globally unique IPv4 address. As such, even there is repetition in the 4-byte IPv4 address portion in VPN-IPv4 addresses, the VPN-IPv4 addresses are still globally unique.
The routes received by PE from CE are IPv4 routes, which shall be imported into the VRF routing table, attached with a RD at that moment. In common practice, the same RD is set for all routes from the same subscriber site.
Route Target Attribute:
Route Target attribute identifies the collection of sites where a route can be used, i.e., the sites where the route can be received, in other words, the sites from which the routes can be received by the PE. All PEs connected with the sites indicated in the Route Target will receive routes with such an attribute. After PE receives a route with such an attribute, it adds the route into the corresponding routing table.
There are two collections of Route Target attribute in PE: one is used to be attached to the routes received from a certain site, and is referred to as Export Route Targets; the other is used to decide which routes can be imported into the routing table of the site, and is referred to as Import Route Targets.
Through matching the Route Target attribute carried with the routes, the VPN membership can be obtained. Route Target attribute matching operation can be used to filter the routing information received by PE.
VPN Message Forwarding Process:
In RFC 2547bis standard, VPN message forwarding employs two layers of labels. The first layer (outer layer) label is exchanged in the backbone network, and represents an LSP from a PE to the opposite PE; with the label, a VPN message can reach the opposite PE along the LSP. When the message is transmitted from the opposite PE to a CE, the second layer (inner layer) label is used; the inner layer label indicates the destination site of the message, more specifically, the destination CE. In this way, in accordance with the inner layer label, the interface for message forwarding can be found. In special cases, if two sites belonging to the same VPN are connected to the same PE, there is no problem about how to reach the opposite PE, what is to be solved is how to reach the opposite CE.
Distribute VPN Routing Information in BGP:
In RFC 2547bis standard, CEs and PEs transmit routing information to each other in IGP or EBGP; PEs obtain the routing table of the VPN, and store it in a separate VRF. General IP connectivity between PEs is ensured in IGP, VPN composition information and routing information is transmitted in IBGP, and VRFs are updated accordingly. The routing tables in CEs are updated through route switching between PEs and CEs, and thereby the route switching between CEs is accomplished.
BGP communication is carried out on two layers: inside the autonomous systems (IBGP) and between the autonomous systems (EBGP). PE-PE sessions are IBGP sessions; while PE-CE sessions are EBGP sessions.
The transmission of VPN composition information and routing information between PEs in BGP is accomplished in Multiprotocol Extensions BGP (abbreviated as “MBGP”). Details of MBGP are described in IETF RFC 2283 “Multiprotocol Extensions for BGP-4”. MBGP is downward compatible, i.e., it supports both conventional IPv4 address family and other address families (e.g., VPN-IPv4 address family). With the route target carried in MBGP, the routes of a specific VPN can be known by only other members of the VPN, so that it becomes possible for the communication between BGP/MPLS VPN members.
In data transmission via a VPN, the subscriber often designates the QoS, for example, priority of the data to be transmitted. The higher the priority of the data to be transmitted is, the sooner the VPN will transmit the data on the premise of ensured transmission reliability. In practical situations, there is no matured MPLS VPN QoS solution at present. As a result, the subscribers' requirements can't be met.
The main reason for above situation is: different NBVPNs accessed by the same group of PEs share resources with each other by multiplexing outer layer labels in the MPLS label stack.
Theoretically, though the resources of outer layer tunnels can be ensured by providing DiffServ-aware (perform forwarding in different priorities by DiffServ Code point (DSCP) field) or with similar solutions. In these reference models, none of the devices in each VPN knows resource condition in the backbone network, moreover, there is a resource competition between several VPNs at each node, therefore it is a difficult task to ensure resources for each VPN. Such a sharing and competition mechanism brings more complexity to QoS assurance for VPNs.
The Provider Provisioned Virtual Private Networks (abbreviated as “PPVPN”) workgroup designated by IETF is divided into two workgroups after the Vienna Seminar held in July, 2003: L2 VPN and L3 VPN workgroups. In their latest charters, no QoS solution was included. In the prior VPN reference models, the QoS problem still exists. In IETF's “draft-martini-12circuit-trans-mpls-10.txt” and “draft-martini-12circuit-encap-rapls-04.txt” (both of them are the foundation of L2 VPN), the representation for QoS problem was “QoS related issues are not discussed in this draft”. In “draft-IETF-L3VPN-rfc2547bis-01.txt” (it is the foundation of BGP/MPLS VPN), the representation for QoS problem was simply mentioned: “existing L3 QoS capabilities can be applied to labeled packets through the use of the ‘experimental’ bits in the shim header”. However, the problem is, L3 QoS itself is a complex and unsolved problem. Therefore, the QoS problem in L2 VPN/L3 VPN is left unsolved.
On the ITU-T SG13 Seminar held in July, 2003, the proposal for investigation of generalized VPN (GVPN) “Y.nbvpn-decomp” was approved as the initial documentation for generalized Network Based Virtual Private Network (abbreviated as “NBVPN”) as well as the foundation for classification of building blocks of GVPN. In “Y.nbvpn-decomp”, some functional entities were classified, aiming to simplify VPN problems, so as to define the techniques and mechanisms required by network operators to provide expected VPN networks. However, the reference model provided in “Y.nbvpn-decomp” and corresponding QoS problems are identical to the VPN reference model and QoS problems put forth by IETF. Therefore, the QoS problems have not been solved satisfactorily; as a result, the entire VPN model is not generalized enough to meet the requirements of operators who expect to provide QoS assured VPN services. Furthermore, though VPN subscribers are permitted to access the VPN, it is uninsured that they can obtain required resources as in Asynchronous Transfer Mode (abbreviated as “ATM”) /Frame Relay (abbreviated as “FR”) /Digital Data Network (abbreviated as “DDN”) networks.